1. Field of the Invention
The present invention relates to a method and apparatus for delivering content in a Dynamic Content Delivery (DCD) service. More particularly, the present invention relates to a method and apparatus for submitting user-created content to share with other users.
2. Description of the Related Art
Due to the development of communication technologies, mobile communication, which focused on voice calls at its initial stage, is now introducing to the market messaging services such as Short Message Service (SMS) and Multimedia Messaging Service (MMS), and various supplementary services such as Internet access service and video call service, and is also considering the introduction of personalized content delivery services taking into account the fact that a majority of mobile communication devices are carried by individuals.
Considering such market characteristics, Open Mobile Alliance (OMA), which has established many application layer standards for portable terminals, is conducting research on a Dynamic Content Delivery (DCD) technology in the OMA Content Delivery (CA) Working Group, it's the OMA affiliated organization. DCD is a technology capable of providing services that deliver user-desired contents on a personalized basis in line with the situations that practical application of Internet services on mobile terminals is not made because of the market demands stated above, the inconvenient searches, the limited input means, and the low service speeds, and with the growing user demands for personalized services.
Problems of the prior art and solutions for addressing the same will be described clearly below based on an OMA CD technology, which is one of the content provision standards. However, this is a mere example used to give better understanding of the invention, and the present invention is not limited to the OMA CD technology and can be applied to various other content provision technologies.
FIG. 1 illustrates the architecture and interface configuration of a DCD service system to which the present invention is applicable.
Referring to FIG. 1, the DCD system includes a DCD client 120 and a DCD server 110. The DCD client 120 is located in a mobile terminal and used by the mobile terminal to access the DCD server 110. The DCD client 120 includes modules that perform their associated three logical functions: a Subscription and Administration function, a Content Delivery and Storage Management function, and a Client Application Interaction function. The Subscription and Administration function module 121 is responsible for exchanging service administration information with the DCD server 110, and the Content Delivery and Storage Management function module 123 is responsible for managing content received from the DCD server 110. The Client Application Interaction function module 125 supports functions for accessing the DCD service from a DCD Enabled Client Application 20 using its DCD client 120.
The DCD server 110 offers a network function based on DCD service-related applications. The DCD server 110 includes modules that perform their associated two logical functions: a Subscription and Administration function and a Distribution and Adaptation function. The Subscription and Administration function module 111 is responsible for exchanging service administration information with the DCD client 120, and the Distribution and Adaptation function module 113 provides DCD content and a DCD content notification to the DCD client 120. Table 1 below defines interfaces used between the components (logical entities) in FIG. 1.
TABLE 1InterfacesDefinitionDCD-1Bi-directional point-to-point interface between the DCD Server and the DCD Client. This interface isused by the DCD Client to send content requests to the DCD Server, and to receive responses.DCD-2Uni-directional interface between the DCD Server and the DCD Client. This interface is used by theDCD Server to push notifications and/or content to the DCD Client. The DCD-2 interface couldmanifest itself as point-to-point push interface or point-to-multipoint broadcast interface.DCD-3Bi-directional point-to-point interface between the DCD Server and the DCD Client. This interface isused by the DCD Server and the DCD Client to exchange service administration and configurationinformation.DCD-CPRUni-directional interface between the DCD Content Provider and the DCD Server. This interface isused by the Content Provider to register new content channels with the DCD Server.DCD-Bi-directional interface between the DCD Content Provider and the DCD Server. This interface isCPDEused by the Content Provider to publish content at the DCD Server and by the DCD Server to retrieve content from the Content Provider. The interface could also be used for exchange of administration information, if applicable. While the interface is bi-directional, only the DCD Server provided interface functions are a subject for standardization.DCD-CARUni-directional interface between the DCD-Enabled Client Application and the DCD Client. Thisinterface is used by the DCD-Enabled Client Application to register with the DCD Client when theapplication is installed on a handset.DCD-Bi-directional interface between the DCD-Enabled Client Application and the DCD Client. ThisCADEinterface is used by the DCD Client to send notifications and/or content to the DCD-Enabled ClientApplication and by the DCD-Enabled Client Application to retrieve content from the DCD Client.The interface could also be used for exchange of administration information, if applicable. While theinterface is bi-directional, only the DCD Client provided interface functions are a subject forstandardization.
In the DCD system, content metadata (Metadata, Content Format) is defined to deliver content. The term “content metadata” refers to dynamic settings and rules, or content information, for controlling DCD content delivery. Table 2 below gives definitions of elements and attributes in the content metadata.
TABLE 2Provided toDECA (DCDEnabledOriginatedClientNameTypeCardinalityDescriptionData TypeUsed byfromApplication)content-E1Contains theStructureDS (DCDCP (ContentYESmetadatafollowingServer),Provider)attributes:DC (DCDcontent-updatedClient)content-idchannel-idmime-typecontent-lengthcontent-typescontent-namereplaces-content-idcontent-pricecontent-delivery-notificationdelivery-prioritycontent-encodingcontent-addresscontent-storage-locationcontent-block-idparental-ratingdeliver-todeliver-atcontent-expirationdelivery-spreaddeliver-when-roamingnetwork-selectionaux-content-linkContains thefollowing sub-elementsdeliver-per-locationdeliver-per-presencedeliver-per-xdmscontent-A0 . . . 1Time when theStringDCCP, DSYESupdatedcontent item waslast updated.SHALL conformto the “date-time”definition in[RFC3339]. Inaddition, anuppercase “T”character SHALLbe used toseparate date andtime, and anuppercase “Z”character SHALLbe present in theabsence of anumeric timezone offset.content-idA1Identifier set byStringDS, DCCPYESthe ContentProvider, andunique within theDCD ServiceProvider'sdomain. Themain purpose ofthe content ID isto enableapplication levelconfirmation andresumption ofcontent delivery.Implementationin XML schemawill use the“AnyURI” datatype.channel-idA0 . . . 1A list of ChannelList ofDS, DCCPYESIDs as assignedStringsby the DCDServer. TheContent Providerincludes thisattribute toassociate contentitems with DCDchannelsmime-typeA1The MIME typeStringDS, DCCPYESof the contentitem.content-A1The size in bytesStringDS, DCCP, DSYESlengthof the contentitem.content-A0 . . . 1A list of stringsList ofCPYEStypesthat describe theStringschannel contentto enableassociation orfiltering e.g. by“type”,“category”, “tag”,or “relation”content-A0 . . . 1Name of contentStringCPYESnamein a humanreadable format.replaces-A0 . . . 1Content ID of anStringDS, DCCPYEScontent-idoutdated contentitem that, ifpresent in thestorage of theDCD Server orDCD Client,should bereplaced with thiscontent item.Implementationin XML schemawill use the“AnyURI” datatype.content-A0 . . . 1Indicates theStringDCCP, DSYESpriceprice (amount andcurrency) of thiscontent item. Thepurpose is to letthe user know theprice of thecontent anddecide if he wantsto retrieve itcontent-A0 . . . 1Indicates the needBooleanDS, DCCP, DSNOdelivery-for, or status of,notificationdeliveryacknowledgementfor this contentitem.This attributeshould be set to“true” if user ischarged fordelivery of thiscontent item(subject to DCDService ProviderPolicy)Values:0—False (*)1—Truedelivery-A0 . . . 1The deliveryEnumeratedDS, DCCP, DSNOprioritypriorityassociated withthis content item.Values:1—Low2—Medium (*)3—High4—Emergencycontent-A0 . . . 1Encoding that hasStringDCDSNOencodingbeen applied tothe content item,e.g. GZIP ordeflatecompression.content-A0 . . . 1An addressStringDCDSYESaddress(URL) where thecontent item canbe directlyretrieved by theDCD Client viathe DCD-1interface.content-A0 . . . 1Location of theStringDCDCYESstorage-content item inlocationthe DCD Clientmanaged storagecontent-A1Identifies whichStringDSCPYESblock-idmultiple contentitems can beassociated as ablock. May beused by the DCDServer for contentaggregation/bundling.parental-A0 . . . 1Content ratingStringDS, DCCPYESratingper FCC “TVParentalGuidelines” orsimilar localregulatoryrequirements.May be used bythe DCD Serverfor contentselection/filtering, and byDCD Client forthe same in thebroadcast case.deliver-toA0 . . . 1A particular set ofStringDSCPNOusers to receivethe content.deliver-atA0 . . . 1Time at which theStringDSCPNODCD Servershould deliver acontent item.content-A0 . . . 1The expectedStringDS, DCCPYESexpirationlifetime of thecontent item indevice storage,and the time untilwhich the contentitem can bedirectly retrieved(if a contentaddress attributewas provided).delivery-A0 . . . 1The period overStringDSCPNOspreadwhich the DCDServer canrandomizedelivery, for thepurpose of loadspreading.deliver-A0 . . . 1Indicates whetherBooleanDSCPNOwhen-the content itemroamingshould beautomaticallydelivered orretrieved viapoint-to-pointinterfaces if theuser is roamingValues:0—False (*)1—Truenetwork-A0 . . . 1DescendingStringCP, DS,DSNOselectionpriority-ordered,comma-separatedlist ofnetwork/bearertypes for use incontent delivery,selected perarbitrarydeployment-specific criteriafor networkselection (e.g.GPRS vs. UMTSvs. Wi-Fi) basedon delivery cost,bandwidth,quality of service,etc. DCD Clientand DCD Serverapply thesecriteria forcontent deliveryover DCD-1 andDCD-2interfaces. One ormore of“UMTS”,“WiMAX”,“LTE”, “802.11”,“CBS”,“BCAST”.aux-A0 . . . 1Provides theStringDS, DCCP, DSNOcontent-Content ID orlinklink to additionalcontent that isrelated to thecontent beingdelivered. Theintent is tosupport pre-fetching contentreferred to by themain content itemor likely to berequested later.deliver-E10 . . . 1A rule forStringDSCPNOper-matching alocationlocation at whichdelivery shouldbe allowed. Therule should bespecified by theDCD ContentProvider, theDCD Server, orthe DCD EnabledClientApplication basedon the formatpublished by theService Providerdeliver-E10 . . . 1A rule forStringDSCPNOper-allowing deliverypresencebased uponmatching aPresence attributedeliver-E10 . . . 1A rule forStringDSCPNOper-xdmsallowing deliverybased uponmatching aXDMS attribute.
In the prior art, the content metadata for content delivery is generally used only when content is created by the DCD server or content provider and delivered from the DCD server to the DCD client.
The DCD client can also deliver (submit) content to the DCD server according to the prior art. However, in the prior art, when the DCD client submits content, the DCD client delivers the content in the form of an opaque content package that the DCD system cannot interpret, without delivering the content metadata. Thus, the DCD server can not comprehend the content information, making it inefficient to post or share the content, and error is apt to occur.